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Abstract 

Traditional  techniques  for  examining  wireless  networks 
use  physical  link  characteristics  such  as  Signal-to-Noise 
(SNR)  ratios  to  assess  the  performance  of  wireless  networks. 
Such  measurements  may  not  be  reliable  indicators  of 
available  bandwidth.  This  work  describes  two  new  software 
applications  developed  at  NASA  Glenn  Research  Center  for 
the  investigation  of  wireless  networks. 

GPSIPerf  combines  measurements  of  Transmission 
Control  Protocol  (TCP)  throughput  with  Global  Positioning 
System  (GPS)  coordinates  to  give  users  a  map  of  wireless 
bandwidth  for  outdoor  environments  where  a  wireless 
infrastructure  has  been  deployed.  GPSIPerfView  combines 
the  data  provided  by  GPSIPerf  with  high-resolution  digital 
elevation  maps  (DEM)  to  help  users  visualize  and  assess  the 
impact  of  elevation  features  on  wireless  networks  in  a  given 
sample  area. 

These  applications  were  used  to  examine  TCP  throughput 
in  several  wireless  network  configurations  at  desert  field  sites 
near  Hanksville,  Utah  during  May  of  2004.  Use  of  GPSIPerf 
and  GPSIPerfView  provides  a  geographically  referenced 
picture  of  the  extent  and  deterioration  of  TCP  throughput  in 
tested  wireless  network  configurations.  GPSIPerf  results 
from  field-testing  in  Utah  suggest  that  it  can  be  useful  in 
assessing  other  wireless  network  architectures,  and  may  be 
useful  to  future  human-robotic  exploration  missions. 


Recommendations 

•  GPSIPerf  should  be  used  to  characterize  the  TCP 
throughput  in  wireless  network  architectures  at  field 
research  sites. 

•  Visualization  of  wireless  network  characteristics  should 
be  done  in  terms  of  its  geographic  context. 

•  More  work  needs  to  be  done  to  create  and  incorporate 
additional  indicators  of  wireless  network  speed,  signal 
strength  and  associative  capabilities  in  GPSIPerf. 

•  Concerted  effort  should  be  expended  to  create  and  use 
radio  wave  propagation  models  that  are  accurate  over 
distances  (<1  km)  appropriate  to  wireless  networks. 

1.  Background 

Building  and  maintaining  wireless  networks  is  not  an  easy 
task.  Two  separate  approaches  may  be  used  together  to  best 
determine  the  configuration  of  hardware  in  a  sparse,  outdoor 
wireless  network:  modeling  and  empirical  determinations. 

Modeling  wireless  networks  is  difficult  and  any  given 
model’s  best  estimate  of  the  signal  strength  and  the  quality  of 
such  networks  is  often  inaccurate.  Engineers  of  wireless 
networks,  lacking  models  sufficient  to  their  needs,  are  often 
relegated  to  empirical  determinations  of  these  network 
characteristics.  Such  determinations  utilize  varying  arrays  of 
hardware  and  software  and  may  be  chosen  over  wireless 
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network  modeling  when  planning  and  maintaining  wireless 
networks.  Some  of  these  hardware  and/or  software  packages 
are  quite  expensive  while  others  are  relatively  inexpensive, 
but  may  not  adequately  characterize  the  wireless  network  in 
question. 

For  example,  these  tools  may  enable  autonomous  robotic 
planetary  surface  explorers  to  map  an  exploration  terrain 
before  or  during  future  NASA  human-robotic  missions.  This 
information  is  useful  because  human  explorers  require 
constant  communication  during  extra-vehicular  activity 
(EVA).  GPSIPerf  and  GPSIPerfView  may  allow  mission 
control  and  surface  explorers  to  predict,  identify,  and 
measure  gaps  in  communications  availability,  understand 
their  actual  exploration  limits  spatially,  or  understand  where 
modifications  to  exploration  communications  infrastructure 
are  required  to  complete  a  particular  objective. 

1.1  Existing  Software  Solutions 

The  number  of  wireless  networking  software  utilities  that 
are  currently  under  active  development  serves  is  a  good 
indicator  of  the  amount  of  attention  that  field  of  wireless 
networking  is  currently  receiving.  Most  of  these  applications 
perform  various  types  of  network  auditing  utility. 

NetStumbler  (ref.  1)  and  Kismet  (ref.  2)  are  examples  of 
two  popular  wireless  network-auditing  utilities.  Ostensibly, 
these  tools  may  be  used  to: 

•  Locate  wireless  network  AP’s  (access  points) 

•  Verify/identify  network  configuration. 

•  Identify  areas  with  strong  and  weak  wireless 
radiofrequency  (RF)  signals  from  the  access  point. 

•  Detect  interfering  networks. 

•  Assist  with  pointing  directional  antennas  in  complex 
network  architectures. 

These  applications  are  capable  of  reporting  wireless  network 
parameters  such  as  MAC  Address,  Service  Set  ID  (SSID), 
Name,  Channel,  Speed,  Encryption  Status  and  Signal-to- 
Noise  ratio.  Kismet,  unlike  NetStumbler  is  a  passive 
monitor;  in  addition  to  identifying  access  points  without 
announcing  itself,  it  can  also  detect  hidden  networks  on  the 
basis  of  analyzing  intercepted  packets. 

Few,  if  any  wireless  networking  utilities  attempt  to 
measure  bandwidth  at  the  application  level.  Most  products 
rely  on  layer- 1  RF  signal  strength  as  the  link  quality 
measurement.  Signal  strength  is  an  instantaneous 
measurement  that  can  vary  dramatically  from  one  second  to 
the  next.  Throughput,  in  terms  of  bandwidth,  is  an  expression 
of  the  total  data  transport  capability  of  wireless  networks 
over  a  period  of  time.  It  is  approximated  by  parameters  such 
as  “Speed”  that  are  reported  by  NetStumbler. 

The  term  “goodput”  narrows  the  definition  of  throughput 
to  be  the  empirical  amount  of  data  actually  usable  by 
applications  over  time.  Goodput  is  typically  some  fraction  of 
the  total  throughput.  Dropped  frames,  retransmission  of  data, 


and  the  addition  of  protocol  headers  in  the  IP  stack  are  all 
elements  that  reduce  the  usable  throughput  over  a  network 
link.  Bit  error  is  especially  common  over  wireless  links  and 
typically  results  in  a  loss  of  TCP  throughput.  Wireless 
network  engineers  may  be  interested  in  throughput,  but 
software  developers  and  operators  should  be  more  interested 
in  the  goodput  of  a  network. 

The  National  Laboratory  for  Applied  Network  Research 
(NLANR)  Distributed  Application  Support  Team  (DAST) 
has  created  a  utility,  iperf,  which  measures  the  maximum 
TCP  bandwidth  of  any  existing  network  connection  (ref.  3). 
Measurement  of  TCP  bandwidth  using  iperf  is  an  indicator  of 
goodput.  Unfortunately,  iperf,  by  itself,  does  not  include  or 
make  simple  the  inclusion  of  Global  Positioning  System 
(GPS)  data.  The  use  of  GPS  data  in  other  wireless  utilities 
such  as  NetStumbler  and  Kismet  aids  in  establishing  the 
geographical  extent  of  wireless  networks  with  GPS  reference 
data. 

The  experiments  performed  in  this  report  made  use  of 
wireless  equipment  based  on  the  IEEE  802.1  lb  standard.  The 
GPSIperf  tool  measures  “goodput”  achieved  at  the  TCP 
layer,  so  this  tool  is  independent  of  the  layer- 1  (PHY) 
wireless  standard  employed.  This  means  GPSIPerf  could  also 
be  used  to  measure  the  performance  of  large  open  area 
Internet  Protocol-based  wireless  technologies,  including 
802.16  (WiMAX),  802.20  (MBWA),  and  so  on.  GPSIperf 
only  requires  that  the  client  nodes  be  receiving  adequate  GPS 
signals,  be  within  a  wireless  coverage  area,  have  a  GPSIPerf 
server  running  somewhere  on  the  network,  and  that  the  client 
maintain  an  active  TCP  connection  to  the  GPSIPerf  server. 

The  development  and  use  of  networked  wireless 
applications  could  benefit  by  measures  of  goodput  combined 
with  GPS  data.  These  combined  measurements  can  help  to 
answer  questions  that  the  increasing  use  of  wireless  networks 
has  brought  to  our  attention  such  as: 

•  Where  will  my  application  work? 

•  What  kind  of  data  throughput  can  I  expect? 

•  How  long  will  this  download/upload  take? 

The  responses  to  these  questions  are  more  germane  to  the 
developers  and  operators  of  applications  than  are  the  speeds 
reported  by  access-points  or  measurements  of  signal-to-noise 
ratio  provided  by  other  wireless  utilities.  These  indicators  are 
primarily  hardware  level  estimates  of  wireless  service 
quality.  What  is  required  is  software  driven  estimates  similar 
to  those  provided  by  “iperf.” 

1.2  New  Tools 

This  work  describes  two  new  applications  for  the  testing 
and  visualization  of  wireless  network  performance.  These 
tools,  when  used  in  tandem,  may  be  used  to  plan,  deploy  and 
test  the  efficiency  of  wireless  networks  in  field  research 
settings. 
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GPSIPerf  was  developed  to  pair  Global  Positioning 
System  (GPS)  data  with  measurements  of  wireless  network 
performance.  Specifically,  GPSIPerf  measures  network 
maximum  TCP  bandwidth.  GPSIPerf  gathers  bandwidth 
measurements  via  the  NLANR  Distributed  Application 
Support  Team’s  “iperf’  utility.  GPSIPerfView  is  a  tool  that 
was  developed  to  visualize  GPSIPerf  measurements  in  a 
geographical  context.  United  States  Geological  Survey 
(USGS)  (ref.  4)  Digital  Elevation  Map  (DEM)  data  is  used  to 
create  a  virtual  terrain  upon  which  GPSIPerf  data  may  be 
mapped. 

GPSIPerfView  also  includes  a  configurable  tool  that 
projects  the  results  of  wireless  network  signal  loss 
calculations  onto  a  Digital  Elevation  Map  (DEM). 
Calculations  of  signal  loss  are  derived  from  the  National 
Telecommunications  and  Information  Administration’s 
(NTIA)  Irregular  Terrain  Model  (ITM)  for  radio  propagation 
(ref.  5). 

2.  GPSIPerf  Implementation  and  Testing 

Development  and  testing  of  GPSIPerf  and  GPSIPerfView 
took  place  in  several  different  locations.  Much  of  GPSIPerf 


was  written  during  the  Fall  of  2003  and  Spring  of  2004. 
However,  some  of  its  development  occurred  in  situ  during 
GPSIPerf  testing.  This  paper  will  address  its  capabilities  and 
the  approaches  used  for  the  implementation  of  specific 
mechanisms  within  GPSIPerf  rather  than  detailing  a  history 
of  its  development. 

Development  of  GPSIPerfView  occurred  after  the  spring 
of  2004  field-testing  during  the  late  spring  and  summer  of 
2004.  GPSIPerfView  provides  an  interface  by  which  to  view 
previously  gathered  GPSIPerf  results  although  it  has  not 
been  thoroughly  tested  under  field  conditions. 

Both  GPSIPerf  and  GPSIPerfView  were  developed  using 
Microsoft  Visual  Studio  .Net  2003.  Operability  of  these 
applications  was  tested  on  Windows  2000  and  Windows  XP 
operating  systems. 

Hardware  used  in  the  preliminary  development  and  testing 
of  GPSIPerf  is  as  follows: 

•  DeLorme  USB  Earthmate  2  GPS  Receiver  (ref.  6). 

•  Sager  Notebook  Model  8887  (ref.  7). 

Wireless  network  connectivity  on  the  laptop  was 
established  using  a  PRISM-based  chipset  with  Intersil 
(version  1.07.37)  network  drivers. 


Figure  1. — The  GPSIPerf  Interface — The  GPSIPerf  interface  offers  users  the  ability  to  configure 
iperf,  GPS  data  acquisition  and  CORBA  communications.  A  simple  X-Y  plot  is  used  to 
visualize  GPSIPerf  measurements  over  time  and  over  geographic  location  (geographic  location 
shown  above).  Users  may  also  have  GPSIPerf  announce  relative  bandwidth  percentages  aloud 
when  CRT/LCD  visibility  is  limited  (e.g.,  in  bright  daylight).  Logs  and  specific  configurations 
may  also  be  loaded  by  users. 
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2.1  GPSIPerf 

This  section  introduces  and  describes  the  first  of  the 
software  components  used  for  wireless  throughput 
investigations.  Descriptions  of  field  testing  can  be  found  in 
section  3. 

2.1.1  GPSIPerf- — User  Interface. — GPSIPerf  provides  an 
interface  to  configure  GPS  data  acquisition  and  iperf 
parameters  as  well  as  a  simple  visualization  and  logging  tool 
for  correlating  GPS  location  with  TCP  throughput 
measurements.  GPSIPerf  s  key  features  are  enumerated  here 
and  depicted  in  figure  1 . 

Users  are  given  the  ability  to  configure  and  execute  iperf 
clients.  These  clients  interact  with  running  iperf  servers 
located  at  the  opposite  end  of  a  wireless  link.  Cross-checks 
of  the  iperf  configuration  against  command  line  parameters 
are  available  for  users  who  are  familiar  with  the  simple 
command  line  executable  provided  by  NLANR. 

Users  may  track  the  bandwidth  and  location  from  a 
configured  interface  by  merely  clicking  the  “Begin 
Tracking”  button.  While  actively  tracking,  a  properly 
configured  GPSIPerf  process  is  able  to  record  location  and 
iperf  bandwidth  measurements.  These  measurements  are 
updated  every  second  in  logs,  text  and  visually  on  a  scatter 
plot.  Furthermore,  users  may  choose  to  mark  points  of 
interest  during  tracking  mode  using  the  “Add  Pos.  as 
WayPt.”  Button.  Way  Points  are  displayed  visually  on  the 
positional  scatter  plot  and  can  be  stored  in  separate  log  files. 

Simple  means  are  made  to  store  and  auto-load 
configuration  sets.  File-based  storage  of  configurations  must 
be  explicitly  selected  before  they  are  loaded,  whereas  auto- 
loaded  settings  are  stored  in  the  registry  and  are  used  to 
populate  the  various  parameter  values  when  GPSIPerf  is  first 
executed. 

GPSIPerf  session  log  files  may  be  saved  either  in  a  binary 
format  or  as  comma-separated  volumes  (CSV).  CSV  files 
may  be  easily  loaded  into  Excel  and  other  data  processing 
programs  for  post-collection  analyses. 

Recently,  the  ability  to  establish  a  connection  with  a 
remote  CORBA-based  location/bandwidth  service  has  been 
added  to  the  GPSIPerf  interface.  GPSIPerf-based  reports  of 
bandwidth  and  position  from  multiple  GPSIPerf  clients  can 
be  logged  and/or  tracked  from  the  CORBA  server. 
Additionally,  our  visualization  software,  GPSIPerfView,  can 
contact  the  server  to  determine  the  whereabouts  and  most 
recent  throughput  of  all  GPSIPerf  clients. 

2.1.2  GPSIPerf— GPS  Data  Acquisition. — GPS  libraries 
were  used  that  were  capable  of  parsing  NMEA  (National 
Marine  Electronics  Association)  formatted  output  from  a 
GPS  Receiver  connected  to  a  RS-232  (COM) 
communication  port. 

It  was  determined  early  on  in  the  software  development 
process  that  COM  port  access  to  GPS  data  was  highly 
desirable  as  software  solutions  implementing  such  access 
would  be  able  to  utilize  a  wide  array  of  GPS  receivers. 
Unfortunately,  there  were  few  choices  for  inexpensive,  self¬ 


powering  (i.e.,  no  batteries  required),  light-weight  GPS 
receivers.  The  DeLorme  USB  Earthmate  2  offered  the  best 
solution  in  terms  of  energy-efficiency,  size,  weight  and 
expense. 

The  choice  of  the  DeLorme  GPS  receiver  added  some 
complications  in  terms  of  data  access  due  to  its  use  of  USB 
ports  as  opposed  to  the  more  common  COM  ports.  It  was 
necessary  to  install  DeLorme ’s  Earthmate  Drivers  (ref.  8) 
using  an  option  to  add  support  for  2nd  Party  applications  for 
development  and  testing  with  this  unit.  This  installation 
option  created  a  virtual  COM  port  through  which  GPS  Data 
could  be  transferred  to  a  non-Delorme  Application. 

Data  access  to  this  virtual  COM  port  is  somewhat 
problematic  as  the  current  implementation  of  the  COM  port 
access  code  in  GPSIPerf  does  not  seem  to  initialize  the  GPS 
unit  properly.  Java-code  utilizing  the  Java  Serial 
Communications  Application  Programming  Interface  (API) 
is  used  to  perform  a  one-time  initialization  of  the  GPS  unit  at 
4800  baud  8-N-l.  NMEA  1.8.3  strings  were  reliably 
produced  by  the  DeLorme  GPS  unit  following  this 
initialization  step.  GPSIPerf  was  capable  of  creating 
connections  to  the  COM  Port  with  parameters  specified  in 
the  user  interface  once  successful  initialization  had  occurred 
(fig.  2).  The  default  parameters  provided  were  usually 
enough  to  get  the  GPS  unit  up  and  running. 


Figure  2. — The  GPSIPerf  GPS  Configuration 
Interface — Relatively  little  information  must 
be  entered  in  this  tab  to  properly  configure  the 
GPS  for  data  acquisition. 
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2.1.3  GPSIPerf- — IPerf  Modifications.— The  TCP 
Bandwidth  network  performance  monitor,  iperf,  was  used  to 
make  measurements  of  TCP  throughput.  This  program  was 
compiled  from  source  code  provided  by  NLANR/DAST  web 
site  and  executed  in  a  separate  thread  from  that  of  the 
GPSIPerf  user  interface.  The  iperf  executable  was  started 
using  command  line  parameters  derived  from  options 
selected  through  the  user  interface  (fig.  3).  Output  from  the 
iperf  was  logged  using  output  redirection  classes.  Finally,  a 
mechanism  for  cleanly  shutting  down  the  iperf  client  using 
file  semaphores  was  added  in  order  to  avoid  segmentation 
faults  and  premature  termination  of  the  iperf  server. 

Configuration  of  GPSIPerf  to  recreate  a  usable  string  of 
the  command-line  parameters  was  trivial  and  did  not  require 
modifications  to  iperf  source  code.  The  most  complicated 
task  in  the  execution  of  iperf  was  properly  redirecting  its 
output  to  the  GPSIPerf  executable  for  collation  with  GPS 
data  and  reporting.  This  redirection  was  handled  within  the 
GPSIPerf  code  rather  than  that  of  iperf. 

Implementations  of  file-semaphore  shutdown  mechanisms 
as  well  as  the  new  logging  output  formats  did  require  some 
small  modifications  of  the  iperf  code.  Changes  to  the  output 
procedure  were  minimal.  The  first  of  these  changes  reduced 
the  header  reporting  to  once  per  execution  of  iperf  as 
opposed  to  the  reporting  of  header  information  every  20 
lines.  The  second  change  to  the  output  procedure  modified 
the  TCP  output  string  to  contain  the  word  “data”  at  the 
beginning  of  every  reporting  line.  This  word  was  recognized 
by  the  GPSIPerf  output  parser  as  indicating  that  the  data 
coming  from  the  iperf  could  be  used  in  reporting  the 
Bandwidth  measurements. 

Changes  to  iperf  that  provided  a  mechanism  for  clean 
shutdown  of  the  iperf  client  as  dictated  by  the  user’s 
interaction  with  the  GPSIPerf  executable  were  a  little  more 
complex.  A  separate  thread  (Quitter)  was  created  that  polled 
for  the  existence  of  a  file  named  “quitter. quit”  in  the 
execution  directory.  This  empty  file  was  created  whenever 
the  user  prompted  GPSIPerf  to  “Stop  Tracking”  or  when 
GPSIPerf  was  terminated  during  active  tracking.  When  that 
file  existed  this  thread  would  alert  all  other  threads  to  stop 
and  signal  iperf  shutdown.  This  implementation  allowed  for 
shutdown  of  the  iperf  client  in  a  manner  that  avoided  iperf 
server  segmentation  faults  and  premature  termination. 
Earlier,  elegant  solutions  involving  piped  signals  and  drastic 
measures  such  as  external  process  termination  had  both 
failed  to  produce  the  desired  results  on  the  iperf  server-side. 

Overall  the  configuration  of  and  alterations  to  iperf  proved 
to  be  very  easy.  Readable  and  well-maintained  code  made 
changes  easy  and  the  flexibility  and  power  of  the  initial  code 
ensured  that  no  new  options  for  reporting  need  be 
established. 

2.1.3  GPSIPerf- — CORBA  Integration. — Users  of 
GPSIPerf  may  wish  to  report  their  bandwidth  and  location  to 
a  central  service  for  potential  use  by  other  applications.  The 
integration  of  the  Common  Object  Request  Broker 


Figure  3. — The  GPSIPerf  iperf  Configuration 
Interface — The  most  common  IPerf 

configuration  options  are  available  in  this  tab 
to  configure  iperf  for  data  acquisition. 

Architecture  (CORBA)  into  GPSIPerf  allows  users  to  send 
small  amounts  of  data  to  such  a  service. 

The  CORBA  is  a  middleware  specification  for  creating 
distributed  computing  frameworks  created  by  the  Object 
Management  Group  (ref.  9).  Mico  (ref.  10)  is  an  open  source 
implementation  of  the  CORBA  specifications  that  has  proved 
useful  in  our  experience  (ref.  11).  Mico  version  2.3.11  was 
used  as  the  backbone  CORBA  implementation  for  GPSIPerf 
and  GPSIPerf  Data  server  inter-process  communications. 

The  interoperability  of  computing  components  using 
CORBA  is  defined  by  an  IDL  (Interface  Definition 
Language)  document.  This  document  serves  as  a  contract 
between  client  and  servers.  The  IDL  document  used  for 
GPSIPerf  services  is  relatively  simple  (listing  1).  Typical 
reporting  of  GPSIPerf  client  to  a  GPSIPerf  Data  Server 
consists  of  a  single  “AddPoint”  call.  Bandwidth  used  for 
CORBA  messages  is  not  figured  into  the  final  TCP 
bandwidth  provided  by  the  iperf  executable.  However,  the 
size  of  the  data  payload  of  this  message  is  less  than  200  bytes 
and  is  transmitted  by  GPSIPerf  once  every  second  when 
updated  positional  and  bandwidth  data  are  available  (i.e., 
during  active  tracking).  The  impact  of  these  messages  on 
throughput  estimates  is,  at  this  time,  thought  to  be  negligible. 

The  configuration  of  GPSIPerf  to  connect  to  a  data  server 
was  relatively  simple.  Users  needed  to  specify  only  the  desire 


NASA/TM— 2005-213580 


5 


interface  GPSlPerf_Data 

{ 

struct  Gl_Point  { 
long  Time; 
double  X; 
double  Y; 
double  Az; 
double  BW; 
long  NumSats; 
long  Fix; 
double  PDOP; 
double  VDOP; 
double  HDOP; 
string  UTMZone; 
long  DS; 

typedef  sequence  <Gl_Point>  Gl_List; 
typedef  sequence  <string>  Gl_clients; 
void  AddPoint(in  string  client,  in  Gl_Point  data); 
void  AddData(in  string  client,  in  Gl_List  data); 
void  GetData(in  string  client,  out  Gl_List  data); 
void  GetPoint(in  string  client,  out  Gl_Point  data); 
void  GetClients(out  Gl_Clients  clients); 


Listing  1 . — Interface  Definition  Language  document  used  to  pass  GPSIPerf  data  to  a  central  service  for  later  use  by  other 
clients  such  as  GPSIPerfView.  The  highlighted  “AddPoint”  call  is  used  by  GPSIPerf  to  register  itself  and  add  data  to  a 
dataset  maintained  by  a  remote  GPSIPerf  Data  Server.  “GetPoint”  and  “GetClients”  are  used  by  GPSIPerfView  to 
update  client  positions. 


to  use  CORBA,  and  the  hostname  and  port  of  the  GPSIPerf 
Data  Server  under  a  “CORBA”  tab  that  was  similar  to  those 
of  “IPerf ’  and  “GPS”  configuration  tabs.  Successful  CORBA 
connections  allow  this  configuration  data  to  be  stored  and 
used  as  “Auto-Load”  defaults  for  future  use. 

Data  was  not  sent  to  the  server  until  Clients  began  to  track. 
Tracking  initialized  the  connection  to  server.  Once  the 
connection  to  the  server  was  successfully  established  data 
was  on  each  periodic  update  of  the  user  interface  (1  second 
intervals). 

Implementation  of  the  CORBA  client  interface  was 
relatively  simple  under  Windows  as  the  interface  data 
structure  definition  (i.e.,  GI  Point)  closely  followed  a 
structure  that  was  used  often  within  the  GPSIPerf  code. 
Integration  of  CORBA  into  the  GPSIPerf  code  was  further 
facilitated  by  the  Windows  Microsoft  Foundation  Classes 
API.  Using  this  API  dispensed  with  the  need  for  threading 
requirements  that  the  periodic  calls  to  the  server  might  have 
caused.  Windows  “SetTimer”  and  “KillTimer”  calls  were 
used  to  mimic  periodic  calls  to  “AddData”  that  might 
otherwise  have  been  performed  by  a  concurrent  thread.  It  is 
worth  noting  that,  during  the  system  timer  events  GPSIPerf 
visualization,  log  and  textual  data  were  updated,  in  addition 
to  adding  data  to  the  GPSIPerf  Data  server.  Although  the 
granularity  of  the  Windows  timers  can  be  somewhat  coarse 
(milliseconds),  it  was  deemed  sufficient  for  our  use. 

2.2  GPSIPerfView 

The  goal  in  the  development  of  GPSIPerfView  was  to 
provide  users  with  a  means  by  which  GPSIPerf  data  could  be 
regarded  in  terms  of  the  geographic  setting  within  which  the 
data  was  derived.  United  States  Geological  Survey  (USGS) 


Digital  Elevation  Maps  (DEM’s)  were  used  to  provide  a 
geological  context  for  field  observations. 

The  GPSIPerfView  interface  offers  users  the  following 
capabilities: 

•  DEM  loading  and  visualization  (fig.  4). 

•  GPSIPerf  CSV  log  loading  and  visualization. 

•  Irregular  Terrain  Model  Radio  Loss  calculations  and 
visualization. 

Additionally,  GPSIPerf  has  the  ability  to  create  CORBA 
connections  to  get  “live”  GPSIPerf  client  information  from  a 
GPSIPerf  Data  Server  as  well  as  utilities  for  object  control, 
DEM  subset  selection,  application  of  shaders/textures  to 
DEM  data,  marker  selection,  and  the  extraction  of 
application  screen  shots.  This  set  of  functionality  helps  to 
make  the  GPSIPerfView  application  a  powerful  tool  for  the 
investigation,  planning,  maintenance  and  testing  of  wireless 
networks  to  be  created  and  used  in  field  research. 

2.2.1  GPSIPerfView— DEM  Data. — USGS  DEM  data  is 
readily  available  from  a  number  of  commercial  and  free 
sources.  Much  of  this  data  has  been  converted  to  the  ISO 
8211  Spatial  Data  Transfer  Standard  (SDTS)  (ref.  12).  SDTS 
data  is  arranged  in  a  set  of  files  that  are  compact  and  well- 
organized.  However,  deriving  DEM  data  from  these  file  is 
not  a  trivial  task.  Two  different  freely  available  libraries  offer 
solutions  to  SDTS  data  access.  The  first  of  these  libraries 
SDTS++  is  implemented  in  C++  (ref.  13).  This  library  relies 
heavily  on  stream  capabilities  provided  to  it  by  underlying 
Boost  libraries  (ref.  14).  The  second  library,  fipsl23,  is  an 
older  SDTS  library  developed  in  C  (ref.  15).  It  use  has  been 
deprecated  in  favor  of  the  SDTS++  libraries. 

During  our  implementation  of  SDTS  data  access  it  was 
found  that  fipsl23  provided  faster  load  times  and  was  more 
stable  than  the  SDTS++.  On  average  fips!23  library 
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Figure  4. — GPSIPerfView’s  Interface.  GPSIPerfView  supports  opening  and  manipulation  of  the  data  from 
multiple  DEM  data  files  and  GPSIPerf  data  logs.  Individual  views  of  DEM’s  like  that  of  Factory  Butte, 
Utah  (shown  above)  can  be  shaded  or  textured  according  to  a  number  of  different  schemes.  The  coloration 
scheme  for  this  DEM  was  derived  from  a  loaded  image  file. 


implementations  of  DEM  data  loading  methods  performed  4 
to  5  times  faster  and  loaded  the  range  of  DEM’s  that  we  used 
for  testing  more  reliably.  In  rare  cases,  some  SDTS  files 
caused  SDTS++  library-based  loading  implementations  to 
produce  page  faults.  The  cause  of  these  faults  is  unknown  but 
was  reported  to  SDTS++  mailing  lists  and  remains 
unremedied  at  the  time  of  this  writing. 

The  underlying  visualization  framework  for  DEM  data  was 
used  by  all  other  visual  components  in  GPSIPerf.  This 
visualization  technique  can  be  separated  into  two  distinct 
parts:  the  rendering  context  or  view  and  the  scene  graph  used 
to  render  DEM  and  other  data  to  the  screen.  OpenGL  was 
chosen  as  the  underlying  rendering  library  for  DEM  data  as 
there  was  plenty  of  support  available  for  OpenGL 
development  both  from  external  (e.g.,  internet)  and  in-house 
sources  (ref.  16).  OpenGL  visualization  in  GPSIPerfView’s 
interface  used  the  GLEnabledView  code  originally  created 
by  Alessandro  Falappa  (ref.  17).  This  class  provided  a  well- 
documented  entry  point  in  to  the  Window’s  OpenGL 
rendering  context  and  enabled  rapid  development  of  mouse 
and  keyboard  control  procedures. 

Rendering  of  DEM  scene-graphs  within  individual  views 
(fig.  4)  and  the  two-dimensional  dialog  rendering  of  DEM 
data  (fig.  5)  are  heavily  derived  from  code  found  in  Jamie 
Moyer’s  Linux-based  DEM  visualization  application:  kdem 


(ref.  18).  This  code  was  ported  to  a  Windows-based  library; 
GraphDEM,  and  supported  rapid  development  of  many  new 
visualization  items  and  controllers.  Support  for  views  and 
controllers  such  as  those  GPSIPerf  data,  Irregular  Terrain 
Model  results  and  map  markers  was  primarily  provided  as 
subclasses  derived  from  this  framework  of  base  classes. 

2.2.2  GPSIPerfView— GPSIPerf  Data—  The  goal  of 
viewing  GPSIPerf  data  in  the  appropriate  geographical 
context  was  achieved  through  decomposition  into  three 
subtasks: 

•  Loading  of  the  GPSIPerf  Data. 

•  Referencing  loaded  positional  information  into  the 
appropriate  DEM  areas. 

•  Visualization  and  control  of  GPSIPerf  Data  on  the 
surface  of  the  Digital  Elevation  map. 

Loading  of  GPSIPerf  log  data  was  accomplished  with  little 
difficulty.  Writing  routines  for  loading  the  comma-separated 
fields  in  the  files  into  a  structure  similar  to  the  GPSIPerf 
Data  Server’s  IDL  GI  Point  data  was  very  straightforward. 
However,  users  had  to  be  given  the  ability  to  load  multiple 
log  files  at  once.  This  required  an  additional  identifier  in  the 
structure  of  each  data  point  to  indicate  the  data’s  source. 
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Figure  5. — Two-dimensional  rendering  of  a  loaded  DEM.  This  interface  provides  users  with  the 
ability  to  choose  subsets  using  a  mouse  click  and  drag  technique  as  well  as  select  key  latitude  and 
longitude  points  with  the  mouse  or  by  keyboard  entry.  The  interface  is  versatile  and  aids  users  with 
Irregular  Terrain  Model  Beacon,  Point  Marker  and  Subset  selections. 


Loaded  GPSIPerf  data  was  next  normalized  to  the  extents 
and  granularity  of  the  DEM.  The  typical  resolutions  of  DEM 
data  that  were  used  was  10  or  30  m.  GPSIPerfView  provided 
a  separate  means  (i.e.,  a  resolution  controller)  through  which 
a  user  coidd  decrease  or  increase  the  resolution  of  the 
rendered  DEM.  Rendered  resolution  could  not  be  increased 
above  that  of  the  original  SDTS  data,  but  could  be  dropped 
to  a  single  representative  point.  This  complicated  the 
referencing  of  positional  data  to  the  grid,  but  allowed  for 
decreased  rendering  times  for  very  large,  high  resolution 
DEM’s.  GPSIPerf  Data  points  were  aligned  according  to  the 
rendered  DEM  resolution  rather  than  the  absolute  resolution 
to  maintain  positional  integrity.  Finally,  GPSIPerf  data  for 
locales  not  encompassed  by  the  bounds  of  the  DEM  to  which 
they  were  assigned  were  ignored. 

Visualization  of  GPSIPerf  data  used  some  unique 
approaches  (fig.  6).  The  first  of  these  was  a  user-selected 
color  scheme.  Red,  green,  blue  was  the  default  color  scheme 
for  indication  of  the  relative  TCP  throughput  of  the  data.  Red 
spheres  by  default  represented  the  greatest  relative 
throughput,  whereas  blue  spheres  indicated  the  lowest 
relative  throughputs.  Users  could  rearrange  the  order  of  the 
RGB  components  of  this  scheme  or  opt  to  use  black/white  as 
the  highest  and  white/black  as  the  lowest  bandwidths  and 
shades  of  grey  for  those  lying  in  between.  Sets  of  data  that 
were  loaded  from  different  log  files  were  bounded  by 
distinctly  colored  dashed  boxes  to  aid  in  their  differentiation. 


Another  unique  visualization  capability  was  provided  in 
allowing  the  user  to  change  the  size,  and  thus  visibility  of  the 
spheres.  Finally,  users  were  able  to  lift  GPSIPerf  data  en 
masse  from  the  DEM  data  using  a  simple  mouse  movement 
or  keyboard  control. 

2.2.3  GPSIPerfView — The  Longley-Rice  Irregular 
Terrain  Model. — The  Longley-Rice  Irregular  Terrain  Model 
(ITM)  (ref.  19)  was  used  in  GPSIPerfView  to  provide  a 
qualitative  context  in  which  users  could  gauge  apparent 
increases  and  decreases  in  GPSIPerf  TCP  throughput.  ITM  is 
generally  considered  an  industry  standard  for  prediction  of 
the  median  attenuation  of  a  radio  signal  as  a  function  of 
distance  and  the  variability  of  that  signal  in  time  and  space. 
This  attenuation  is  reported  in  terms  of  decibel  (dB)  loss. 
However,  ITM  solutions  do  not  incorporate  losses  due  to 
Fresnel  zones  or  multipathing  and  are  limited  to  distances 
between  1  and  20  km. 

The  ITM  model  is  configured  using  a  number  of  different 
user-specified  parameters.  The  values  of  these  parameters 
were  selected  through  a  dialog  which  was  shown  when  the 
user  chose  to  run  an  ITM  Model  (fig.  7).  The  user  was  also 
provided  with  the  opportunity  to  save  and  load  other 
configurations  in  addition  to  hand  entering  the  profiles. 

The  calculations  used  for  point-to-point  radio-wave 
attenuation  solutions  were  derived  from  C++  code  developed 
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Figure  6. — GPSIPerf  data  successfully  combined  with  USGS  DEM  data.  This  figure  shows  data 
from  three  separate  Tropos,  Inc.,  hardware  testing  runs  of  GPSIPerf  in  Factory  Butte,  Utah. 
Following  the  WiFi  “hot  spot”  notion,  green  (cool)  and  blue  (cold)  spheres  indicate  areas  of 
increasingly  low  TCP  throughput  relative  to  those  of  the  high  throughput  red  (hot)  spheres. 
Differentiation  of  each  of  these  data  series  is  aided  by  providing  different  colored  bounding 
boxes  for  each  of  the  datasets. 


Figure  7. — Configuration  Dialog  for  the  Irregular  Terrain  Model's  calculation  of  radio 
signal  attenuation.  Users  can  choose  the  question  mark  boxes  for  information  and 
suggestion  on  values  for  Surface  Refractivity,  Dielectric  Constant,  Conductivity  and 
Radio  Climate.  Latitude  and  longitude  may  be  selected  from  a  two-dimensional 
depiction  of  the  DEM  (fig.  5).  The  horizontal  extents,  radial  resolutions  and  linear 
resolutions  of  the  solutions  are  also  selected  here. 
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by  Fred  Najmy  and  Alaka  Paul  at  the  National  Telecom¬ 
munications  and  Information  Administration/Institute  for 
Telecommunication  Services  (NTIA/ITS)  (ref.  19).  Only  two 
changes  were  made  to  the  code  prior  to  its  inclusion  in 
GPSIPerfView.  First,  the  model,  originally  supplied  as  code 
for  a  dynamic  link  library  was  converted  to  a  static  library. 
Second,  the  model  was  modified  to  return  a  qualitative 
indicator  of  the  solutions  (i.e.,  line  of  sight,  troposcatter 
dominant,  etc.) 

ITM  solutions  are  performed  iteratively.  Vertical  profiles 
were  first  derived  from  the  DEM.  The  chosen  transmitter 
position  served  as  one  endpoint  of  the  profile.  Other 
elevation  points  in  the  profile  were  sampled  at  increasing 
distance  radiating  from  the  center  point  at  specified  intervals 
over  a  specified  range.  The  increment  in  distance  and 
maximum  range  were  selected  by  the  user  as  Profile  Extent 
(m),  and  Linear  Resolution  (m),  respectively.  The  process  of 
creating  elevation  profiles  was  repeated  over  360°  at  an 
interval  selected  by  the  user  as  Angular  Resolution.  Points  in 
the  elevation  profiles  that  did  not  correspond  exactly  to  DEM 
data  samples  were  calculated  using  interpolation  from 
surrounding,  known  DEM  elevation  points. 

At  each  point  of  each  elevation  profile  a  solution  for  radio¬ 
wave  attenuation  was  calculated.  Thus,  for  a  horizontal 
extent  of  1000  m  with  a  linear  resolution  of  10  m  and  an 
angular  resolution  of  1  degree,  36000  (360  ■  100) 

calculations  were  performed.  The  results  and  profiles  used 
for  all  calculations  are  written  to  a  single  file  for  later  review 
upon  successful  completion  of  the  ITM  iterations. 

Solutions  for  the  model  at  horizontal  distances  less  than  1 
km  are  not  strictly  valid.  However,  qualitative  comparison 
with  solutions  at  positions  at  or  beyond  this  inner  limit 
indicates  strong  coherence  with  solutions  located  within  this 
limit.  Qualitative  indicators  such  as  line-of-sight  versus 
single  or  double  horizon  troposcatter  or  diffraction 
dominance  as  well  as  the  calculated  decibel  loss  are 
consistent  with  the  line  of  sight  indicators  and  increasing 
linear  distance  from  the  transmitter’s  origin. 

The  results  of  these  calculations  were  added  to  the  DEM 
scene  for  rendering.  Qualitative  solution  polygons  were 
placed  at  the  horizontal  extent  of  each  radial  arm.  These 
color  and  shape  of  these  polygons  indicated  line  of  sight, 
double  or  single  horizon  and  troposcatter  or  diffraction 
dominance.  Additionally,  solutions  for  each  point  are  used  to 
indicate  relative  levels  of  signal  loss.  Points  with  the  lowest 
signal  loss  (or  best  transmission  levels)  are  red  whereas 
points  with  higher  loss  progress  through  green  to  blue 
(fig.  8). 

A  separate  dialog  was  developed  to  provide  the  user  with 
another  visualization  solution  for  viewing  individual  ITM 
result  profiles.  This  dialog  allowed  the  user  to  view  precise 
heading  and  elevation  profiles  for  each  of  the  profiles  in  the 
ITM  solution.  Additionally,  the  user  has  the  ability  to  take 
screen  shots  of  individual  profiles  for  later  examination 
(fig.  9). 


Figure  8. — Results  of  ITM  calculations  using  DEM 
data  from  Factory  Butte,  Utah.  Vertical  elevations 
were  sampled  over  a  2  km  radius  at  10  m  linear 
resolution  once  per  degree  over  360°  (72000 
calculations)  were  used  to  create  this  image.  Red 
areas  nearest  the  transmitter  center  point  indicate 
good  radio-wave  propagation.  Lower  transmissions 
indicated  by  the  blue  areas  in  the  canyon  reflect  the 
loss  of  line  of  sight  on  radio  propagation. 


Figure  9. — Elevation  profile  from  the  ITM  Results 
dialog.  The  radio  transmitter  is  located  on  the  left 
vertical  axis.  The  white  dashed  line  is  the  line  of  sight 
from  the  transmitter  to  the  receiver.  Red  areas  on  the 
profile  indicate  areas  of  relatively  high  signal  loss 
whereas  green  indicate  areas  of  low  signal  loss.  The 
small  rise  in  the  middle  left  of  the  profile  shows  an 
area  of  increased  signal  loss  directly  to  its  right  and 
behind  it  relative  to  the  transmitter  location. 
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Figure  10. — TCP  Throughput  over  distance  at  the  Dry  Valley  Test  Site  near  Flanksville, 
Utah  as  recorded  by  GPSIPerf.  Approaches  to  a  stationary  access  point  were  made  from 
the  south,  north,  and  west.  Dependency  on  terrain  features  and  line-of-sight  signal 
propagation  may  have  caused  the  differences  in  the  distance  at  which  throughput  first 
begins  to  change.  Evidence  for  rapidly  fluctuating  adapter  rates  was  also  seen  at  0.73 
and  0.83  km  in  throughput  measurements  for  western  and  northern  traverse  legs, 
respectively. 


3.  GPSIPerf  Field  Tests 

GPSIPerf  was  tested  during  the  first  week  of  May  2004. 
Two  field  sites  and  three  different  hardware  access  point 
configurations  were  used  during  this  field  testing  period. 
Field  conditions  were  dry  to  very  dry,  and  temperatures  were 
between  85  and  97  °F. 

The  first  of  the  testing  sites  was  south  of  Hanksville,  Utah 
in  Dry  Valley.  The  purpose  of  tests  performed  here  was  to 
establish  the  throughput  capabilities  of  non-elevated  and 
elevated  (fig.  11)  commodity  access  points  to  clients  at 
varying  distances  over  relatively  uniform  terrain.  These  tests 
served  as  reference  points  to  later  testing  done  with  more 
complex  access  point  configurations. 

The  second  testing  site  was  at  Factory  Butte.  This  location 
provided  long  flat  stretches  of  road  to  perform  bandwidth 
throughput  distance  testing  of  Tropos  repeaters  as  well  as 
Vivato,  Inc.,  antenna  arrays.  Furthermore,  a  dry  wash  at  this 
site  was  used  to  gather  bandwidth  throughput  measurements 
for  clients  in  environments  with  complex  geometry.  The 
latter  form  of  testing  was  referred  to  as  “canyon  testing.” 


3.1.1  Dry  Valley  Test  Site — Ground  Level  Access 
Point. — The  access  point  (AP)  hardware  configuration 
consisted  of  an  approximately  2  m  high,  tripod-mounted 
Linksys  WAP11  802.11b  wireless  access  point  (30  mW 
output)  situated  at  38.294  N.  latitude,  110.715  W  longitude. 
An  “iperf  ’  server  was  started  on  a  laptop.  This  computer  was 
connected  with  a  direct  cable  connection  to  the  Linksys 
access  point.  GPSIPerf  was  run  on  a  separate  laptop  that  was 
equipped  with  a  DeLorme  USB  EarthMate2  GPS  unit  and  an 
Avaya  PCMCIA  wireless  networking  card.  Configuration  of 
the  “iperf’  within  GPSIPerf  used  the  iperf  server  laptop’s 
static  IP  as  the  server  address  and  a  message  interval  of  1 
transmission  per  second.  TCP  messages  were  configured  to  a 
window-size  of  256  kB  with  an  8  kB  buffer  length.  The 
following  command  was  created  by  GPSIPerf  to  execute  the 
iperf  client: 

[PATH\]iperf.exe  -c  XXX.XXX.XXX.XXX  -1  8K  -w  256K  -i  1  -f 
m  -t  10000 

where  PATH  was  the  location  of  the  iperf  executable  and 
XXX.XXX.XXX.XXX  is  the  IP  address  of  the  laptop. 
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The  GPS  unit  was  situated  on  the  dashboard  of  the  test 
vehicle.  An  external,  8  dBi  co-linear  antenna  was  connected 
to  the  Avaya  card  and  was  magnet  mounted  to  the  exterior 
roof  of  the  vehicle.  The  vehicle  was  driven  along  roads  north, 
south,  and  west  of  the  access  point  at  a  rate  not  greater  than 

10  mph. 

GPSIPerf  was  used  to  measure  the  TCP  throughput  during 
multiple  traverses  of  roads  found  in  the  test  site.  GPSIPerf 
performed  well  for  these  test.  Some  difficulties  acquiring 
GPS  coordinates  were  encountered  while  increasing  distance 
from  the  access  point.  However,  it  is  not  clear  at  this  time 
whether  the  difficulties  were  related  to  hardware  or  software 
components  in  the  test.  TCP  throughput  measurements 
without  valid  GPS  coordinates  were  discarded  during  the 
data  processing  phase. 

Testing  from  each  of  these  three  cardinal  directions  driving 
towards  the  access  point  revealed  the  effects  of  distance  (i.e., 
signal  attenuation)  on  TCP  throughput  (fig.  10).  The  distance 
at  which  TCP  throughput  drops  from  values  ca.  5  Mbps  to 
those  around  1  Mbps  differs  with  each  of  the  tested 
directions.  Access  point  approaches  from  the  south  and  north 
revealed  rapid  increases  in  the  TCP  throughput  at  400  and 
450  m.  Approaches  from  the  west  showed  similar  rapid 
increases  in  throughput  at  700  m.  The  jump  from  low  to  high 
throughput,  which  was  an  indicator  of  the  hardware 
configuration’s  capacity  for  rate  adaptation,  occurred  rapidly. 
All  approaches  reached  the  upper  tiers  of  throughput 
performance  within  50  m  once  throughput  levels  began  to 
increase. 

We  also  tested  the  effects  of  multiple  (i.e.,  2)  clients  on 
TCP  throughput.  When  maximum  data  transfer  rate  settings 
are  used  by  multiple  clients,  the  total  bandwidth  available  is 
shared.  That  is,  if  the  access  point  was  capable  of  supporting 

11  Mbps,  then  each  of  the  two  clients  experienced  an  equal 
share  of  the  theoretical  maximum  5.5  Mbps  transfer  rate. 
However,  we  observed  when  one  of  the  clients  is  forced  to 
adopt  a  lower  transfer  rate  (e.g.,  1.1  Mbps),  the  other  client 
was  forced  to  assume  that  rate  as  well. 

One  final  observation  from  our  testing  of  a  non-elevated 
access  point  was  made.  We  noticed  three  distinct  throughput 
tiers  with  this  hardware  configuration.  The  first  two  tiers  are 
tightly  constrained  to  throughputs  of  ~5.2  and  ~4.8  Mbps. 
The  last  tier  is  broader  ranging  from  0  to  1.2  Mbps.  This 
tiered  structure  may  be  an  artifact  of  the  Avaya  card’s  signal¬ 
handling  and  rate  adaptation  schemes. 

3.1.2  Dry  Valley  Test  Site — Elevated  Access  Point. — 
Hardware  configuration  for  the  elevated  access  point  (AP) 
tests  was  similar  to  that  of  the  ground  level  test.  The  only 
change  was  in  the  positioning  of  the  access  point  to  a  higher 
elevation  (fig.  11).  The  difference  in  elevation  between  the 
ground  access  point  (1338.4  m)  and  the  elevated  access  point 
(1390.6  m)  was  ~50  m. 

We  observed  increased  throughput  at  distances  comparable 
to  those  sampled  during  the  ground  level  AP  tests  (fig.  12). 
TCP  throughput  at  levels  up  to  3.8  Mbps  was  measured  at  a 


for  ground-level  and  elevated  TCP  through  put 
testing  at  the  Dry  Valley  Site.  Difference  in 
elevation  between  ground-level  (Blue  dot)  and 
elevated  (Red  dot)  AP  locations  elevation  was 
approximately  50  m. 


Figure  12. — Elevated  access  point  testing.  The 
affects  of  elevated  access  points  on  wireless 
TCP  throughput  were  apparent.  We  measured 
higher  throughputs  at  greater  distances  using 
an  elevated  access  point.  The  area  on  the 
Western  Leg  shows  decreased  throughput  that 
may  be  due  to  multipathing  of  the  wireless 
signal.  Distances  at  which  hardware  adapter 
speed  varies  rapidly  are  also  apparent. 
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Figure  13. — Rapid  Changes  in  adapter  speed  were  seen  in  the  GPSIPerf  TCP  throughput  data.  We  observed 
rapid  fluctuations  in  TCP  throughput  (red  and  blue  lines)  over  time  along  the  Western  Leg  at  the  Dry 
Valley  test  site. 


distance  of  2  km  on  the  western  road.  Throughput  at  this 
level  utilized  the  Avaya’s  5.5  Mbps  rate  adaptation  scheme. 

Several  observations  were  made  during  these  tests  that 
were  similar  to  earlier  notes  made  by  the  research  team 
regarding  the  distance  (~0.8  km)  at  which  wireless  driver  rate 
adaptation  algorithms  have  difficulty  maintaining  a  steady 
connection  with  the  changes  in  signal  from  the  access  point. 
These  rapid  changes  in  adapter  speed  were  apparent  in  the 
GPSIPerf  throughput  data  (fig.  13). 

3.2.1  Factory  Butte — Tropos  Mesh  Network. — Tropos 
(ref.  20)  wireless  mesh  network  hardware  (Wi-Fi  Cell 
Outdoor  Unit  5110)  with  1W  Tx  output  was  used  during  tests 
conducted  at  Factory  Butte,  Utah.  This  unit  offers  broader 
coverage  to  802.11b  networks  as  well  as  adding  rapid 
deployment  capabilities.  Tropos  units  were  configured  to  test 
their  ability  to  extend  wireless  coverage  with  a  GPSIPerf 
client.  Hardware  configuration  was  otherwise  the  same  as 
that  used  in  the  Dry  Valley  tests. 

Tropos  unit  testing  revealed  that  the  use  of  Tropos  mesh 
network  units  can  increase  wireless  network  coverage  quite 
dramatically.  TCP  throughput  remained  high  (-1  Mbps)  even 
at  distances  over  4  km  from  the  access  point  (fig.  14).  The 
pattern  of  rapid  rate  changes  from  5  Mbps  to  2.4  Mbps  at 
(0.8  km)  from  the  access  point  continued.  The  distance 


interval  (0.8  to  1.6  km)  over  which  the  fluctuations  occurred 
appeared  to  be  extended  to  a  distance  of  about  800m  by  the 
presence  of  a  Tropos  node  in  the  vicinity.  This  extension  of 
the  rate  fluctuation  interval  may  have  been  due  to  the 
inability  of  the  card  to  rapidly  associate  with  the  more 
powerful  signal  of  the  Tropos  node. 

A  second  series  of  rapid  fluctuations  from  rates  of 
2.4  Mbps  to  1.7  Mbps  occurred  at  a  distance  of  3.8  km  and 
may  be  associated  with  a  step  down  in  the  card’s  transfer 
rates.  Additionally,  it  is  possible  that  the  observed  transition 
from  1.7  Mbps  rates  to  0.9  Mbps  at  a  distance  of  4.1  km  is 
another  indication  of  rapid  rate  fluctuations.  We  also 
observed  that  once  the  mesh  network  node  was  in  wireless 
range,  it  took  some  time  for  the  wireless  networking  card  to 
associate  with  it. 

3.2.2  Factory  Butte — Vivato  Antenna  Array. — One  of  the 
more  interesting  tests  conducted  at  the  Factory  Butte  site  was 
“canyon”  test.  This  test  utilized  a  Vivato  VP1200  indoor  Wi¬ 
Fi  panel  antenna  (ref.  21).  This  antenna  panel  was  enabled 
with  packet-steering  technology.  Packet-steering  allowed  any 
one  of  13  panels  along  an  arc  of  104°  to  become  the 
dominant  802.11b  signal  source  for  clients.  The  source  panel 
could  change  as  clients  moved  through  the  array’s  signal  arc. 
The  antenna  panel  consisted  of  13  access  points  with  varying 
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Figure  14. — TCP  Throughput  over  Distance.  TCP  Throughput  measurements  remained  high  to  a  distance  of 
4  km  using  Tropos  mesh  networking  hardware.  Distance  intervals  where  rapid  fluctuations  in  TCP 
throughput  are  highlighted  with  blue  boxes.  These  fluctuations  may  have  been  caused  by  slow  wireless 
card  rate  adaptation  algorithms  and  AP  association  schemes. 


signal  strengths.  The  variation  in  signal  strength  depended  on 
the  client  location  relative  to  individual  panels  within  the 
Vivato  array.  An  important  observation  from  our  testing  of 
this  antenna  was  the  clear  need  for  the  development  of  open- 
source  or  intelligent  fast-switching  client  network  card  driver 
software.  We  noted  on  several  occasions  during  testing  that 
our  GPSIPerf  client  switched  from  one  good  access  point  to 
a  weaker  access  point  for  reasons  we  do  not  understand1.  We 
also  noted  that  the  time  it  took  our  Windows  applications 
stack  to  handle  the  handoff  from  one  AP  to  another  was  quite 
long,  on  the  order  of  200ms  to  2  or  3  seconds.  Fast-switching 
client  software  that  “spoofs”  the  operating  system  above  it  to 
make  the  seamless  switch  between  AP’s  would  be  useful  for 
future  GPSIPerf  testing. 

Canyon  testing  was  used  to  simulate  the  effect  of  complex 
geometries  on  802.11b  signal  and  TCP  throughput  when 
doing  ground-based  research.  Such  environments  may  occur 
at  other  sites  on  Earth,  the  Moon  or  Mars.  Although  the  test 
setup  was  not  intended  for  scientific  study  of  radio 
propagation  in  a  desert  canyon,  the  test  was  designed  in  a 
manner  that  was  useful  to  assess  the  utility  of  the  GPSIPerf 
tool.  Future  experiments  could  be  designed  such  that  the 
GPSIPerf  tool  is  used  to  map  TCP  throughput  over  the 
smaller  fractal  dimensions  (i.e.,  nooks  and  crannies) 
represented  within  the  canyon  using  differential  GPS 
technology/equipment. 


'This  is  one  of  the  problems  with  working  with  commercial  off  the  shelf 
technology  with  closed-source  driver  software. 


A  dry  wash  running  perpendicular  to  the  road  used  for  the 
Tropos  testing  was  used  for  this  testing.  The  Vivato  antenna 
array  panel  was  placed  about  10  m  behind  the  lip  of  a  mound 
overlooking  the  canyon,  approximately  20  m  above  the  dry 
wash  bed. 

No  vehicle  was  used  in  these  tests.  We  walked  the  Coal 
Mine  Wash  carrying  a  laptop  that  was  equipped  with  a 
Avaya  802.11b  card  and  a  DeLorme  Earthmate  2  GPS  unit. 
Carrying  the  laptop  had  an  attendant  possibility  of  shielding 
the  wireless  card’s  antenna  from  the  Tropos  array  with  the 
laptop  carrier’s  body.  Therefore,  appropriate  precautions 
were  made  to  avoid  standing  directly  in  the  line-of-sight 
path. 

The  results  indicated  that,  in  general,  the  complex 
geometries  of  the  wash  caused  802.11b  coverage  and  thus 
TCP  throughput  measurements  to  be  variable  over  small 
geographic  distances  (fig.  15).  However,  a  plateau  of 
4.9  Mbps  was  seen  at  a  distance  of  350  m  from  the  access 
point.  These  levels  were  not  consistent  even  within  the  first 
100  m.  TCP  throughput  dropped  somewhat  at  distances  over 
350  m  revealing  rapid  fluctuations  in  adapter  speed  between 
5.0  Mbps  and  1.0  Mbps  rates,  and  failed  entirely  before  the 
500  meter  mark  was  reached. 

As  expected,  large  obstacles  to  the  line-of-sight  between 
laptop  and  access  point,  such  as  boulders  and  other  natural 
rock  formations,  caused  interruptions  in  TCP  throughput. 
The  exact  positions  of  these  features  relative  to  the  client  and 
the  access  point  were  not  noted  so  only  this  qualitative 
correlation  was  noted. 
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Figure  15. — Canyon  Testing  with  the  Vivato  Antenna  Array.  Multiple  Areas  of  very  low  TCP  Throughput 
were  found  during  our  testing  of  GPSIPerf  at  the  Factory  Butte  site’s  Coal  Mine  Wash.  These  areas  of  low 
bandwidth  included  regions  within  100  meters  of  the  Access  Point.  802.11b  coverage  was  spotty  but 
provided  relatively  high  levels  of  throughput  up  to  ~360  meters. 


5.  Discussion 

Use  of  GPSIPerf  for  field  testing  wireless  hardware 
configurations  demonstrated  that  TCP  throughput  was  highly 
susceptible  to  hardware  driver  rate-adaptation,  distance, 
access  point  configuration  and  the  geometry  of  the  terrain 
over  which  the  signal  is  to  propagate.  These  observations 
were  consistent  with  both  RF  propagation  theory  and  the 
observation  of  other  researchers  where  multipath,  attenuation 
of  signal,  and  signal  strength  are  all  factors  in  determining 
the  response  of  a  wireless  network. 

GPSIPerf  provided  a  clear  picture  of  TCP  throughput 
conditions  in  our  remote  wireless  network  sites.  One 
application  of  GPSIPerf  that  immediately  suggests  itself  is 
the  characterization  of  application  level  network  performance 
in  more  conventional,  terrestrial  wireless  network 
architectures.  However,  there  also  exists  the  possibility  of  the 
use  of  GPSIPerf  and  similar  tools  in  extraterrestrial  environs. 

GPSIPerf  may  be  utilized  to  gain  insight  into  «-tier 
application  network  performance  and  data  transfer  between 
automated  and/or  remote  wireless  network  computing 
platforms.  Furthermore,  GPSIPerf  data  might  also  be  used  to 
make  informed,  and  (potentially)  automated,  decisions  about 
when  and  where  such  transactions  can  best  take  place.  This  is 
important  for  the  next  generation  of  space  exploration, 
because  it  seems  that  propagation  of  data  via  wireless 
networks  will  be  the  de  facto  approach  to  performing  remote 
science.  Current  simulations  and  experiments  initiated  with 


the  intent  of  providing  a  baseline  for  interplanetary 
exploration  activities  are  already  taking  this  approach. 
Platforms  such  as  the  Lunar  and  Planetary  Science  Module 
(ref.  21)  are  using  wireless  data  transfer  to  effectively  extend 
NASA’s  capability  to  perform  remote  science. 

Visualization  tools  such  as  GPSIPerfView  can  also  be  used 
as  an  aid  to  gain  insight  into  observed  TCP  throughput 
performance  as  well  as  to  detect  and  plan  around  areas  of 
potentially  poor  performance.  GPSIPerf  supplies  accurate 
TCP  throughput  measurements  that  may  be  geographically 
referenced  within  GPSIPerfView  to  give  the  operators  of 
these  platforms  a  sense  of  terrain  during  missions. 
Furthermore,  GPSIPerfView  offers  operators  the  ability  to 
plan  data  transfers  according  to  surrounding  terrain  and 
prevailing  RF  conditions.  For  example,  the  effect  of  terrain 
features  such  as  hills  and  valleys  on  RF  propagation  can  be 
clearly  seen  using  GPSIPerfView ’s  Irregular  Terrain  Model 
Visualization  tool  (fig.  16).  Areas  with  increased  RF  loss  can 
be  accurately  identified.  Two  approaches  to  exploration 
suggest  themselves: 

1)  These  areas  can  either  be  avoided  when  continuous 
communications  are  desired. 

2)  These  areas  can  be  visited  and  data  collected  can  be 
transferred  when  the  remote  platform  has  moved  to 
environs  that  are  more  conducive  to  data  transfer. 
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GPSIPerfView  is  capable  of  providing  a  geographical  context 
for  RF  propagation.  Test  scenarios  can  be  planned  according  to 
modeled  RF  losses.  Testing  runs  in  which  data  must  be 
transferred  continuously  from  clients  via  wireless  networks  may 
be  restricted  to  areas  marked  with  ‘1’.  Autonomous  exploration 
of  areas  marked  with  a  ‘3’  would  require  subsequent  data 
transfer  from  locations  with  ‘  l’s  or  ‘2’s. 

The  first  approach  might  be  appropriate  for  selecting  and 
sampling  along  a  TCP  throughput-optimized  route  for 
reconnaissance  to  a  known  destination.  The  second  approach 
is  useful  for  exploration  of  areas  similar  to  those  found 
during  our  canyon  tests  at  the  Factory  Butte  where  TCP 
throughput  is  erratic  and  not  consistent  with  projected  RF 
loss  predictions. 

While  GPSIPerf  and  GPSIPerfView  provide  users  with 
useful  information,  there  is  room  for  improvement.  For 
example,  GPSIPerf  could  provide  users  with  more 
information  regarding  the  physical  parameters  of  the  network 
connection.  Such  parameters  include  but  are  not  limited  to 
signal  quality,  signal  strength  and  noise.  These  parameters 
may  not  be  of  interest  to  those  who  are  primarily  interested 
in  application  level  network  performance,  but  they  can  often 
be  informative  to  researchers  who  are  concerned  with  more 
esoteric  aspects  of  observed  wireless  networks. 

GPSIPerfView  also  has  room  for  improvement, 
particularly  in  its  use  of  the  Irregular  Terrain  Model.  The 
model,  as  it  is  implemented,  is  limited  to  a  distance  range 
between  1  and  20  km.  Network  hardware  such  as  the  Tropos 
Mesh  Network  access  points  has  an  effective  range  well  in  to 
the  5  km  range  from  what  we  have  observed.  However, 


common  wireless  network  hardware  such  as  the  Linksys 
access  points  used  at  the  Dry  Valley  test  have  lower  power 
outputs  (30  mW)  and  are  limited  to  ranges  of  less  than  1  km. 
It  is  possible  that  lower  power  requirements  could  force 
networking  hardware  intended  for  extraterrestrial  exploration 
to  have  similar  low  power  outputs.  Thus,  at  some  point,  it 
may  become  necessary  to  provide  RF  propagation  models 
that  are  accurate  over  distances  less  than  1  km.  Similarly, 
efforts  should  be  made  to  provide  updated  models  that  are 
capable  of  modeling  and  accounting  for  RF  multipathing  and 
Fresnel  zones.  The  addition  of  these  parameters  and 
considerations  would  invariably  allow  applications  such  as 
GPSIPerfView  to  provide  users  with  more  accurate 
depictions  of  the  RF  environment. 
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